home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part1 / 2557 < prev    next >
Encoding:
Text File  |  1996-08-06  |  2.6 KB  |  71 lines
  1. Path: ix.netcom.com!netnews
  2. From: miker3@ix.netcom.com (Mike Rubenstein)
  3. Newsgroups: comp.lang.c++,comp.lang.c
  4. Subject: Re: Hungarian notation
  5. Date: Thu, 18 Jan 1996 13:18:41 GMT
  6. Organization: Netcom
  7. Message-ID: <30fe433a.64663744@nntp.ix.netcom.com>
  8. References: <4dhkae$an9@blackice.winternet.com> <821890870snz@genesis.demon.co.uk> <30fd5306.3171520@nntp.ix.netcom.com> <9601181211.AA03705@dxmint.cern.ch>
  9. NNTP-Posting-Host: ix-dc8-24.ix.netcom.com
  10. X-NETCOM-Date: Thu Jan 18  5:18:27 AM PST 1996
  11. X-Newsreader: Forte Agent .99c/16.141
  12.  
  13. Dan Pop <danpop@mail.cern.ch> wrote:
  14.  
  15. > miker3@ix.netcom.com (Mike Rubenstein) writes:
  16. > 
  17. > >There is one possibility that makes the cast to long double
  18. > >potentially dangerous according to the standard.  There is no
  19. > >guarantee in the standard that all possible values of an integral type
  20. > >can be converted to long double.
  21. > 
  22. > Such a guarantee actually exists.  
  23. > 
  24. >     (ANSI classic) 3.2.1.5 Usual arithmetic conversions
  25. > 
  26. >     Many binary operators that expect operands of arithmetic type cause
  27. >     conversions and yield result types in a similar way.  The purpose is
  28. >     to yield a common type, which is also the type of the result.  This
  29. >     pattern is called the usual arithmetic conversions: First, if either
  30. >     operand has type long double, the other operand is converted to long
  31. >     double.
  32. > 
  33. > The last statement (sort of) guarantees that any arithmetic type can be
  34. > safely converted to long double, even if some information is lost in the
  35. > conversion (I'm typing this text on a machine where both long and long
  36. > double have the same size, hence some long values cannot be converted to
  37. > long double without loss of precision).
  38.  
  39. I'm not sure I buy that as a guarantee, presumably for the same reason
  40. you added "(sort of)".
  41.  
  42. #pragma talmudic
  43.  
  44. In the same section, we find
  45.  
  46.     Otherwise, if either operand has type float, the other operand
  47.  
  48.     is converted to float.
  49.  
  50. By your reasoning, this would guarantee that any integral type can be
  51. converted to float, possibly with loss of information. (The previous
  52. cases involve double and long double).
  53.  
  54. But section 6.2.1.3 (ISO) says
  55.  
  56.     When a value of integral type is converted to floating type, 
  57.     if the value being converted is in the range of values that 
  58.     ***can be represented but*** cannot be represented exactly ...
  59.     [emphasis added]
  60.  
  61. If the intention is to require that the conversion be always possible,
  62. the words "can be resprented but" serve no useful purpose.  6.2.1.3
  63. (ISO) seems to indicate the possibility that there are values for some
  64. integral type that cannot be represented even inexactly in some
  65. floating point type.
  66.  
  67. #pragma !talmudic
  68.  
  69.  
  70. Michael M Rubenstein
  71.